Conversation
7f74f9a to
82ed1d2
Compare
rka-oai
approved these changes
Jul 2, 2026
| let output: &'static Mutex<Vec<u8>> = Box::leak(Box::new(Mutex::new(Vec::new()))); | ||
| let subscriber = tracing_subscriber::fmt() | ||
| .with_ansi(false) | ||
| .with_max_level(Level::TRACE) |
Contributor
There was a problem hiding this comment.
The events are emitted as INFO right? Maybe we should set INFO instead of TRACE here?
| #[derive(Clone, Debug, PartialEq, Eq)] | ||
| pub(crate) struct AgentCommunicationContext { | ||
| kind: AgentCommunicationKind, | ||
| pub(crate) sender_thread_id: ThreadId, |
Contributor
There was a problem hiding this comment.
OOC, do we need sender_thread_id to be set to pub(crate)? should other modules be able to access/view it (looks like it’s only accessed within this module, so could it remain private)
bolinfest
added a commit
that referenced
this pull request
Jul 2, 2026
## Why Multi-agent v2 communications currently use separate outbound paths: direct messages, follow-up tasks, and completion results go through `send_inter_agent_communication`, while a spawn's initial message goes through the generic input submission path. That split makes it difficult to add complete communication lifecycle logging in one place. This refactor makes `submit_inter_agent_communication` the common sink for those paths, preparing the follow-up observability work discussed in [#30516](#30516). ## What changed - Routed all current outbound `InterAgentCommunication` paths in `AgentControl`—direct messages, follow-up tasks, completion results, and multi-agent v2 spawn initial messages—through `submit_inter_agent_communication`. - Centralized the actual submission and last-task-message bookkeeping there, providing one place for the follow-up PR to instrument communication creation and successful enqueue. - Left non-communication input handling and the multi-agent v1 spawn flow unchanged. ## Testing - `just test -p codex-core 'agent::control::tests::'` (51 passed) - `just test -p codex-core 'suite::subagent_notifications::encrypted_multi_agent_v2_spawn_sends_agent_message_to_child'` (passed) --- [//]: # (BEGIN SAPLING FOOTER) Stack created with [Sapling](https://sapling-scm.com). Best reviewed with [ReviewStack](https://reviewstack.dev/openai/codex/pull/30867). * #30872 * __->__ #30867
4123e51 to
be18a5e
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Why
#30867 makes
submit_inter_agent_communicationthe common outbound sink for multi-agent v2 communications. This follow-up uses that single point to log every communication lifecycle without requiring new hooks as spawn, messaging, follow-up, or result paths evolve.For each communication, the logs need to identify its type, sender and receiver threads, and content, while correlating the successful send with receipt by the destination mailbox. The logging path must not query externally supplied time providers because those calls can be expensive for app-server clients.
What changed
INFOevents on the OpenTelemetry-exportedcodex_otel.agent_communicationtarget forspawn,message,followup, andresultcommunications.submit_inter_agent_communicationwith the communication kind, sender and receiver thread IDs, content, and submission ID.Vec<UserInput>soOp::InterAgentCommunicationcannot bypass the context-bearing centralized path.The refactor does not change submission IDs, capacity checks, last-task bookkeeping, mailbox ordering, protocol types, rollout data, or model-visible context.
Event shape
Illustrative JSON representation of the two independently emitted records:
[ { "event.name": "codex.agent_communication", "communication_id": "019f20e1-40d1-7890-a123-456789abcdef", "kind": "spawn", "state": "send", "sender_thread_id": "019f20df-fbe1-7890-a123-456789abcdef", "receiver_thread_id": "019f20e1-3f79-7890-a123-456789abcdef", "content": "inspect the repository" }, { "event.name": "codex.agent_communication", "communication_id": "019f20e1-40d1-7890-a123-456789abcdef", "state": "receive" } ]Consumers join the receive record to the send record by
communication_idfor the immutable communication metadata.Testing